Every day, for all sorts of reasons, more and more companies are focusing on the consolidation onto a single protocol network of the multiple specialized networks they directly operate or lease from service providers. These multiple specialized networks are based on diverse networking technologies such as Systems Network Architecture (SNA), Internet Protocol (IP) or Internetwork Packet Exchange (IPX). These companies are making this consolidation one of their top priorities, they are almost exclusively selecting IP (the Internet Protocol) as their protocol of choice. However, for the overwhelming majority of these companies that are using SNA protocols and applications, there still is and will be for the many years to come, a major requirement in this changing environment. The requirement is for the employees of these companies to keep the capability they always had to have access to the huge amount of existing corporate data residing in traditional mainframes and accessible through SNA applications.
In an IP environment, a widely used technique for the transport of SNA information across an IP network is the use of Telnet technologies (TN3270). This technique for SNA “green screen” workstation users is a Client/Server approach. “Host On Demand” from IBM or “WebClient” from CISCO are examples of Client software implementations. Network Utility from IBM or CISCO router's offerings are typical Server implementations (hardware and software). The “Client” piece usually runs within the customer's workstation while the “Server” piece is usually placed in front of the customer's Data Center mainframes (or sometimes directly within the mainframe itself) or within the customer's branch offices. As illustrated in FIG. 3, IP protocols are used between the Server and the Clients, while traditional SNA protocols are used between the Server and the target Applications.
Different kinds of sessions are shown in FIG. 3. An SNA session is a session between an SNA Logical Unit (LU) in the mainframe and the Logical Unit representing the terminal (the TN3270 Client) within the Server. A screen session is a session between the TN3270 Client and the mainframe application. A TCP session is a session between the TN3270 Client and the TN3270 Server.
More information concerning the Internet Protocols, Telnet, TN3270 and Network Utility can be found in the following publications incorporated herewith by reference:    “Systems Network Architecture Technical Overview”, Fifth Edition (January 1994), GC30-3073-04.    “IBM 2216/Network Utility Host Channel Connection”, Erol Lengerli, Jacinta Carbonell, Thomas Grueter; IBM International Technical Support Organization, January 1999, SG24-5303-00.    “IBM Network Utility Description and Configuration Scenarios”, Tim Kearby, Peter Gayek, Gallus Schlegel, Imre Szabo, Zhi-Yong Zhang; IBM International Technical Support Organization, January 1999, SG24-5289-00.    “TCP/IP Tutorial and Technical Overview”, M. Murhammer, O. Atakan, S. Bretz, L. Pugh, K. Suzuki, D. Wood; IBM International Technical Support Organization, Sixth Edition (October 1998), GG24-3376-05.    “Internetworking with TCP/IP—Volume I—Principles, Protocols, and Architecture” Douglas E. Comer, Second Edition, Prentice Hall 1991.    Request For Comments (RFCs) from the Internet Engineering Task Force (IETF):    RFC 1576: TN3270 Current Practices,    RFC 1646: TN3270 Extensions for LU name and Printer Selection,    RFC 1647: TN3270 Enhancements,    RFC 2355: TN3270 Enhancements,    RFC 2474: Definition of the Differentiated Service Filed (DS Field) in the IPv4 and IPv6 Headers,    RFC 2475: An Architecture for Differentiated Services,    RFC 1349: Type of Service in the Internet Protocol Suite.
Telnet 3270 protocols specify that Clients are connected to the hosts via TN3270 Servers. Traditionally, in SNA environments, the data traffic related to screen interaction between a terminal and a host application is characterized as interactive traffic, while the data traffic related to the transfer of files is characterized as batch traffic. Telnet 3270 and SNA Protocols offer to TN3270 Clients the capability to download within the local workstation where the Client operates, files from the host(s) they are connected to. Similarly, it is possible for a Client to upload files from the local workstation to SNA Hosts the Client is in session with.
When a TN3270 Client exchanges files with an SNA Host across a Telnet Server, the packets of information related to the file being exchanged are sent between the Client and its Server using the same sessions (TCP, Screen and SNA sessions as illustrated in FIG. 3) than those used for screen related interactions. This means that data packets related to the transfer of files are using the same priority than the priority used for the interactive traffic due to screen related interactions. This mode of operation violates SNA fundamental rules associated with SNA Class Of Service (COS) and Transmission Priority (TP) within SNA networks. These rules assume that interactive traffic (such as screen related interactions) gets a better treatment within the network than lower priority traffic such as batch traffic (such as file transfer related traffic).
Transfer of large files between Clients and their Servers generate a huge amount of data packets that should not flow on the same priority as the interactive, screen related traffic. As a differentiation is not made, overall response time is severely impacted as now, the true interactive traffic but also the non-SNA data traffic will be penalized by a flooding of data packets related to the exchange of files across the network. Exchanging files consumes bandwidth and processing resources within the network. In fact, from an SNA standpoint, the packets related to the exchange of files between a Client and its Server should have a lower priority than the real interactive traffic allowing the higher priority traffic to get a better service than any other low priority traffic.
FIG. 1 provides a schematic view of two traffic sources (TN3270 Clients) connected to a destination (a TN3270 Server) across an IP Network. From an IP network standpoint, as there is no differentiation between the data traffic due to screen related interactions and the data traffic related to file transfer, all SNA packets are treated the same. The network may be represented as a single queue, with a first come first serve quality of service. In summary, SNA traffic for interactive traffic (screen related interactions) is impacted by the transfer of files. Similarly, non-SNA traffic (such as pure IP data traffic), usually flowing on a lower priority than SNA traffic is also impacted by the potential network flooding due to data packets exchanged across the network during file transfer.
The present invention proposes a solution within the IP network, to get around this response time problem.
It is an object of the present invention to allow TN3270 Clients to dynamically specify a lower IP priority for the traffic related to the exchange of files (batch traffic), than the priority associated to the traffic due to screen related interactions (interactive traffic).
It is a further object of the present invention to allow a TN3270 Server to use the same priority as the priority used by the Client when exchanging information with the Client.